It looks to me like this mapping isn't quite right:

UR_RESULT_ERROR_FUNCTION_ADDRESS_NOT_AVAILABLE
If pFunctionName could be located, but its address couldn't be retrieved.

But see :

• ... If no function of that name exists, cuModuleGetFunction() returns CUDA_ERROR_NOT_FOUND.

To me it seems contradictory for the functionname to be located but it's address not being able to be retrieved when cuda docs state that no function with that name exists?

I think what you have here is fine from a general point of view wrt cuda/hip backends: you have a cuda/hip error that can be returned from multiple driver functions, but it's semantics change depending on which function returned it, so you are mapping it to a UR error that gives more info. I think this is a fine idea (although normally I think it is better to return plugin specific errors with the native error in cases where the native error is more clear than a UR mapping); it just looks like the mapping isn't quite right currently.

Only just read @ldrumm s comment which is making the point a lot more succinctly: #1136 (comment)

Thinking about this further. Maybe it is better to append e.g.:

 + void setPluginSpecificMessage(CUresult cu_res, UR_RESULT UR_res) {
- void setPluginSpecificMessage(CUresult cu_res) {
  const char *error_string;
  const char *error_name;
  cuGetErrorName(cu_res, &error_name);
  cuGetErrorString(cu_res, &error_string);
  char *message = (char *)malloc(strlen(error_string) + strlen(error_name) + 2);
  strcpy(message, error_name);
  strcat(message, "\n");
  strcat(message, error_string);

+ setErrorMessage(message, UR_res);
- setErrorMessage(message, UR_RESULT_ERROR_ADAPTER_SPECIFIC);
  free(message);
}

from

Then this gives the option of passing in a UR_RESULT (or whatever it is called) different from UR_RESULT_ERROR_ADAPTER_SPECIFIC (in such cases that there is a clarifying mapping as I described in my first comment).
Then you can

• preserve the native error
• clarify it by providing a UR mapping if one exists
• If one doesn't exist (which might be the case in this example from your code) then you can pass in UR_RESULT_ERROR_ADAPTER_SPECIFIC, possibly with an accompanying message.

If such a protocol were decided across backends, then documented, this would make it easier to prevent such errors as this example in the future (i.e making mappings from native errors to UR that don't make sense), and provide a consistent error message framework for contributors to use.

yeah FUNCTION_ADDRESS_NOT_AVAILABLE is a CL exclusive failure mode, it must have proliferated when it got renamed to be more generic, I've replaced all uses of it outside of the CL adapter with INVALID_KERNEL_NAME